Subject: White Paper Date: Tue, 17 Mar 92 15:52:12 MST TWAIN Linking applications and images The Issue ^^^^^^^^^ In desktop publishing's early days, most publications contained only text and simple black-and-white line drawings that were output to black-and-white laser printers. In recent years, however, computer hardware and software has become much more sophisticated. Both business professionals and graphic artists can now create and output complex, full-color publications. This near-commercial-quality work may include black-and-white, greyscale, and color images acquired from desktop and hand-held scanners, or from still video, digital cameras or image capture boards. This growth in technology means vendors are faced with a challenge: to supply customers with hardware and software products that enhance productivity by working together seamlessly for an efficient, easy-to-use computing process. Unfortunately, image acquisition remains a difficult process. To acquire and place an image in your publication, you must leave the application in which you are working. Then you must locate and open a hardware driver, set the device options, acquire the image, save it to disk, close the hardware driver, return to the application, then locate and read in the image file from disk. The process is time-consuming and tedious, and not how business professionals, designers, or publishers want to work, particularly with the increasing need for on-demand integration of images acquired in real time. The Solution ^^^^^^^^^^^^ When the image-acquisition issue surfaced, hardware and software developers began defining their own image acquisition interfaces. This was a step in the right direction, but it soon became apparent that high numbers of proprietary interfaces were not the ultimate solution. It's inefficient to require a software developer to write a driver for each device they need to support. Conversely, it doesn't make sense to ask a hardware vendor to write a different driver to interface with each software application. Most importantly, it isn't acceptable that users must deal with many unique application/device driver files. Users need a painless way to get image data into their applications. Software developers need compatibility with the widest range of output devices without writing and maintaining multiple device drivers. Hardware developers need compatibility with the greatest number of applications without application-dependent coding. The most obvious solution to this situation is an open industry interface that directly acquires image data from external sources while within an application. In this scenario, each software developer supports a standard data acquisition manager and each hardware vendor writes one driver for their device. Hardware vendors will benefit because they need only provide one standard driver for their device, which can then be used by all software applications supporting the standard data acquisition interface. Software vendors will be freed from writing and supporting device drivers, or from soliciting support for their own proprietary interface. Software vendors will also benefit because one single interface will support those vendors writing these device drivers. Users will benefit because they can place a smaller set of drivers at the operating system level and take advantage of seamless images acquisition from a large number of applications. History and structure of the TWAIN consortium ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In early 1990, the formation of the Macintosh Scanner Roundtable group heightened the imaging industry's awareness of the need for an open interface. While participation in the roundtable was high, it was difficult to resolve issues and progress was slow. At one of the group's last meetings in 1990, it was suggested that a smaller set of industry leaders form a consortium and create a specification for review, revision, and ultimate adoption by the imaging industry. The TWAIN Working Group was formed with representatives from Aldus, Caere, Eastman Kodak, Hewlett-Packard, and Logitech. The Working Group's primary goal was defined as promoting imaging product use by developing an integrated easy-to-use image acquisition interface and educating users about its existence. A key requirement of participation was that members be willing to represent a broader interest than that of their own company. The number of participants was kept low so the specification could be written quickly, while representation from a wide spectrum of application developers (desktop communications and OCR) and hardware vendors (hand-held, desktop, and high-end color imaging devices) was maintained. The result was that working group members represent diversity in the industry, and bring in-depth imaging experience to both hardware and software development, and marketing fields. At the TWAIN Working Group's first meetings, engineers faced the huge task of reviewing specifications and resolving outstanding requirements issues. Most Working Group companies had written their own interface for direct image acquisition, and these were considered, as well as more than two dozen specifications provided by other companies. No single specification or protocol, including those from operating system vendors, provided the completeness, richness of functionality, and ease of implementation that was required. Eventually, a composite of Silicon Beach/Adobe Plug-ins, an internal Aldus protocol, an HP protocol under development and Logitech's SAPI was used as the basis for TWAIN. TWAIN Working Group engineers participated in monthly workshops to define the specification. A separate Marketing Working Group meets to discuss publishing a toolkit, supporting the interface, and other issues, including how to inform the industry and public about the interface. Besides the TWAIN Working Group, more than 175 major imaging hardware and software companies form a group called the "TWAIN Coalition." This larger group reviewed the TWAIN specification and provided feedback prior to its release. The TWAIN Working Group took comments and suggestions from the TWAIN Coalition, examined the costs and benefits of the modifications, and decided which to incorporate into the specification. Some Coalition members have completed a review of the specification and endorse it as being technically sound and beneficial for the industry; they are identified on an endorser's list available from any Working Group contact. The specification is now nearing completion, and applications and sources supporting TWAIN will soon be available. Goals of the TWAIN Specification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TWAIN was designed to provide a consistent, easy integration of image data between sophisticated input devices and software applications. More detailed Working Group goals for the specification included: o Multiple platform support - The interface must work on the Macintosh and under Windows, but should also have the ability to extend to UNIX, OS/2 and other platforms. Use of platform-specific mechanisms should be kept to a minimum. o Support for multiple devices - These include hand-held scanners, flatbed scanners, slide scanners, image capture boards or frame grabbers, digital cameras and image databases-a broad range of raster image- generating devices. o Widespread acceptance - Provide an interface that is well-defined and enables the majority of the leading hardware and software developers to provide drivers for their devices or include support through their applications. o Extensibility and revisability - As the industry grows, the specification's architecture should be extensible and able to handle new, unknown conditions. Revisions will be backwards-compatible with code written to earlier versions of the specification. o Easy implementation - The interface and its documentation should be clear, well structured, well written, and intuitively designed for developers to learn and write the code for it. o Longevity - While the aim is to provide a solution as quickly as possible, the Working Group is doing all it can to make sure the interface is structurally sound and encompasses all functionality necessary to provide a single solution for the industry that will last for several years, or until such time as a facility like this might be supported at the operating system level. It is a goal of the Working Group that this functionality be incorporated at the operating system level and be TWAIN compatible. o Multidata Capacity - This general data interchange mechanism must be able to transmit data in existing standard formats and native file formats such as TIFF, PICT, and DIB. Furthermore, TWAIN was designed to easily support data type extensions outside the realm of images (such as text, facsimile data and vector graphics.) Architecture ^^^^^^^^^^^^ TWAIN provides a simple, yet rich, methodology for universally connecting TWAIN-compliant applications with TWAIN-aware devices. The model for how applications interact with the source of input data can be described through a four-layer protocol: the Application Layer, Protocol Layer, Acquisition Layer and Device Layer. The acquisition components correspond to these layers and include the application, Source Manager, Source and physical hardware device. The application communicates through the Source Manager to a Source driver which represents the physical hardware device that generates image data. The hardware interface element of the TWAIN architecture is the Source. A Source is a TWAIN entity whose purpose is to get data from a hardware device and provide it to a TWAIN-compliant application. A Source is typically written by the hardware vendor to control their peripheral device. These devices are usually a physical piece of hardware, such as a scanner, although a virtual device (such as an image database) also fits the Source model. The device may be locally connected or remotely accessed over a network. The core element of this architecture is the Source Manager (SM). The SM's primary role is to establish and manage the connections between the application and the sources. The SM allows the user to select the desired source, loads and unloads the selected source, and makes sure that all calls from a particular application are correctly routed to the appropriate source. The SM is implemented as a code resource on the Macintosh and a Dynamically Linked Library (DLL) under Microsoft Windows. Under Windows, there will be only one copy of the SM active in memory at any given time. On the Mac, there will be a separate copy of the SM for each application accessing it. When the application needs to communicate with a Source, it calls the SM with a correctly addressed message. An application never calls a Source directly. Let's review how to acquire an image with TWAIN: From the application, the user first chooses "Select Source" from the menu. "Select Source" identifies the source device from which the image will be acquired, and is only accessed by the user when it's necessary to switch between multiple connected devices. "Select Source" invokes the Source Manager and a selection dialog box appears. Once the source is selected, the user choses "Acquire" to initiate the image acquisition process. "Acquire" brings up the Source Manager to facilitate a process called "capabilities negotiation." This takes place between the application sending messages (describing the data it wants) and the Source (defining the data it can provide). When negotiation is complete, all user interface control is passed to the Source. The Source's user interface allows the user to set scanning options and start the scan. The Source passes the image data back through the Source Manager to the Application, which allows the user to place the image in their document if they haven't already specified its destination. TWAIN implementation allows a high degree of flexibility. Application developers can choose from four different levels of support, which increase in complexity. They include Glue Code, Basic, Advanced, or Custom Support. Source developers can decide among three support options: Basic, Advanced, or Custom. These options give developers the ability to either support TWAIN with minimal engineering investment, or to use TWAIN for greater differentiation through their user interfaces and more complete access to all their product's capabilities. How you can become involved ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Developers: In the U.S or Canada, call 1-800-722-0379 to order the TWAIN Toolkit. Outside U.S. or Canada, call (206) 628-5737 from your fax machine and fax yourself document number 9154, the TWAIN Toolkit order form. The toolkit will contain the TWAIN specification, Source Manager, a header file, code for a sample application and Source, as well as a marketing guide. Developer support will be available from all Working Group companies. Users: Look for the TWAIN logo or name on any hardware or software you purchase. Ask product vendors when they will be supporting TWAIN. Refer developers to any TWAIN Working Group member listed below if they are not yet aware of this interface. Let Working Group companies know how you work with TWAIN, especially if you have ideas on how the interface can be improved or extended to better meet your needs and the way you work. TWAIN Working Group Contacts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Aldus - Developers Desk (206) 628-6593 Caere - Fax Support (408) 354-2743 Eastman Kodak - Support Line (716) 724-1682 Hewlett-Packard - TWAIN Support (303) 350-4830 Logitech - TWAIN Developer Support (510) 713-5DEV A note on our name ^^^^^^^^^^^^^^^^^^ Some of you may have been introduced to the TWAIN interface under the names "Direct-Connect" or "CLASP." While this effort has been promoted under these names in the past, trademark searches turned up too many conflicts for us to feel comfortable using either of these as the final name. After numerous searches, we selected the name TWAIN to describe this interface which brings together two entities, applications and input devices, in a meeting of the "TWAIN." /* end document */